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(54) Computer system and method for executing network mobile code with reduced run-time 
memory space requirements 



(57) A client computer system and associated meth- 
od in a computer network over which are provided pro- 
grams with methods. The client computer is capable of 
executing the programs with reduced run-time memory 
space requirements. Specifically, a network communi- 
cations interface receives the methods of the programs 
and a network communications manager loads uncom- 
pressed in available space in the run-time memory the 
methods when they are received. An execution control- 



ler controls execution of the programs so that the meth- 
ods are invoked and not invoked at various times during 
execution of the programs. A compressor compresses 
in the memory compressible ones of the uncompressed 
methods that are not invoked so that space is made 
available in the run-time memory. The compressor also 
decompresses in available space in the run-time mem- 
ory decompressible ones of the methods so that they 
may be invoked. 
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Description 

The present invention relates to computer systems 
and methods for executtng programs with reduced run- 
time memory space requirements. In particular, the $ 
present invention pertains to computer systems and 
methods in a network for executing code transmitted 
over the network (i.e., network mobile code) so thai the 
run-time memory space requirements of the code is re- 
duced. 10 

BACKGROUND OF THE INVENTION 

Computer systems are now being built or config- 
ured to take advantage of properties of programs whose 15 
code is in an architecture neutral (AN) binary format, 
hereinafter referred to as AN code. Thus, the AN code 
of these programs is independent of the specific archi- 
tecture or platform of the computer system. 

The term architecture is defined for the purposes of 20 
this document to mean the operating characteristics of 
a family of computer models. Examples of specific ar- 
chitectures include Macintosh computers, IBM PC com- 
patible computers using the DOS or Windows operating 
systems, Sun Microsystems computers running the So- 25 
laris operating system : and computer systems using the 
Unix operating system. 

The term architecture specific (AS) is defined for the 
purposes of this document to refer to the requirement 
that the code of certain programs be in a binary format, 30 
hereinafter referred to AS code, for execution only on 
computer systems with a specific computer architec- 
ture. Thus, programs with code written in a conventional 
programming language (e.g., C language) and compiled 
for a specific architecture (e.g., IBM compatible PC) can 35 
only run on that architecture or emulators of that archi- 
tecture. 

The term architecture neutral (AN) is defined for the 
purposes of this document to refer to programs whose 
compiled code can be executed on a variety of computer 40 
systems with different architectures. For example, a 
computer system with a specific architecture can be 
configured with a Java (a trademark of Sun Microsys- 
tems) virtual machine module. The Java virtual machine 
module enables execution of programs with code writ- 45 
ten in the Java programming language and compiled in- 
to bytecode, hereinafter referred to as Java bytecode, 
for the instruction set of the Java virtual machine. Java 
bytecode is independent of the specific architecture of 
the computer system. 

Important features of programs with AN code in- 
clude their portability. For example, since programs in 
AN code can be executed on any computer system con- 
figured to execute the AN code regardless of the com- 
puter system's specific architecture, these programs 
can be easily transported over a network from one com- 
puter system to another. For example, programs com- 
piled into Java bytecode can be executed on any com- 
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puter system with a Java virtual machine module and 
can be easily transported over a network from one com- 
puter system to another using a HotJava (a trademark 
of Sun Microsystems) network communicattons manag- 
er. 

Furthermore, another important feature related to 
the portability of programs compiled into Java bytecode 
is the verifiability of such programs. Specifically, the 
Java virtual machine module can easily verify that these 
programs satisfy predefined integrity criteria. Such in- 
tegrity criteria include stack and data type usage restric- 
tions that ensure that Java bytecode cannot overflow or 
underflow the Java virtual machine module's stack and 
that all instructions in Java bytecode utilize only data 
whose data type matches the data type restrictions for 
those instructions. As a result, a program in Java byte- 
code cannot forge object pointers and generally cannot 
access system resources other than those which the us- 
er has explicitly granted it permission to use. 

For these reasons, computer systems are being 
configured for execution of programs in AN code that 
are received over a network. In fact, in some cases, such 
computer systems may not even require a secondary 
memory (e.g., a hard disk) since the programs are load- 
ed directly into the run-time (i.e., execution-time) mem- 
ory (e.g., random access memory (RAM)) of the com- 
puter system. As a result, the user of such a computer 
system is freed from the cycle of software purchase, in- 
stallation, configuration and upgrade that is currently 
typical of software products. 

The just described features of AN code make it par- 
ticularly attractive for use with small or cheap computer 
systems that are networked and are loaded with AN 
code on demand. For example, these kinds of computer 
systems may be video games, personal digital assist- 
ants (PDAs), cellular phones, or other similar computer 
systems or computer operated devices. 

Unfortunately, however, programs in AN code run 
slower than the same programs in AS code. For exam- 
ple, programs in Java bytecode executed by a Java vir- 
tual machine module typically run 2.5 to 20 times as slow 
as the equivalent program in AS code. Thus, a user of 
a computer system may find it desirable to receive over 
a network AS code of a program so that the AS code 
can be executed on the specific architecture of the com- 
puter system. However, to ensure that these programs 
are securely shipped to a computer system, the network 
would have to be closed or trusted or these programs 
have to have embedded digital signatures which can be 
verified. 

Moreover, AS code which has been generated from 
AN is much larger than the original AN code. For exam- 
ple, AS code generated from Java bytecode is typically 
2 to 5 times the size of the Java bytecode. Thus, a fixed 
amount of run-time memory can hold substantially less 
compiled AS code than AN code. However, as men- 
tioned previously, AS code is much faster than AN code 
from which it is generated and may be the only way to 
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achieve adequate performance. 

I n the just described computer systems, price is ex- 
tremely important. In practice, one of the most signifi- 
cant costs in building such computer systems is the 
amount of run-time memory that is required for execu- s 
tion of loaded programs. It is therefore very important to 
reduce the amount of run-time memory required by 
these computer systems since such a reduction produc- 
es a strong competitive advantage. 

Furthermore, in the computer systems of the type io 
described above, it may not be possible to page to sec- 
ondary memory. In this case, the AN or AS code re- 
ceived over a network could be cached in the run-time 
memory and flushed when its space in the run-time 
memory is required. However, when execution of the is 
flushed program is to be continued, the original code 
must again be downloaded over the network. This sig- 
nificantly affects the execution speed of the program. 
Furthermore, even in computer systems where it is pos- 
sible to page to secondary memory, the time required to 20 
retrieve the code from the secondary memory may be 
too costly 

In the present invention, compression and then de- 
compression of the code of a program received over a 
network is used to reduce the storage cost of the code 25 
in the run-time memory. Since this is much faster than 
flushing code and retrieving it, the execution speed of 
the code is not significantly affected by compression and 
decompression. 

30 

SUMMARY OF THE INVENTION 

In summary, the present invention is a client com- 
puter system and associated method in a computer net- 
work over which are provided programs with methods. 35 
The client computer is capable of executing the pro- 
grams with reduced run-time memory space require- 
ments. The client computer system comprises a run- 
time memory, a communications interface, a network 
communications manager, an execution controller, and 40 
a compressor. 

The network communications interface receives the 
methods of the programs and the network communica- 
tions manager loads uncompressed into available 
space in the run-time memory the methods when they 45 
are received. The execution controller controls execu- 
tion of the programs so that the methods are invoked 
and not invoked. 

The compressor compresses in the run-time mem- 
ory compressible ones of the compressed programs so 
that are not invoked. As a result, space is made availa- 
ble in the run-time memory. The compressor also de- 
compresses in available space in the run-time memory 
decompressible ones of the compressed methods so 
that they may be invoked. 55 

In one embodiment, the compressor decompresses 
the decompressible ones of the compressed methods 
as soon as they are invoked. 



In another embodiment, the compressor decom- 
presses the decompressible ones of the compressed 
methods after a predetermined time interval. 

In still another embodiment, the compressor com- 
presses the compressible ones of the uncompressed 
methods as soon as they are no longer invoked. 

In yet another embodiment, the compressor com- 
presses the compressible ones of the uncompressed 
methods when space in the run-time memory is needed 
but not available. Moreover, in this embodiment, the di- 
ent computer system may further comprise a least re- 
cently invoked list that lists those of the methods that 
are currently not invoked in order of least recently in- 
voked method to most recently invoked method. As a 
result, the compressible ones of the uncompressed 
methods are the least recently invoked methods In the 
least recently invoked list when space in the run-time 
memory is needed but not available. 

In yet still another embodiment, the compressor 
flushes from the run-time memory flushable ones of the 
compressed methods when space in the run-time mem- 
ory is needed but not available. 

As an alternative to the previous embodiment, the 
dient computer system may further comprise a second- 
ary memory. In this case, the compressor stores in the 
secondary memory storable ones of the compressed 
methods when space in the run-time memory is needed 
but not available. Then the compressor retrieves from 
the secondary memory retrievable ones of the com- 
pressed methods that are to be decompressed. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Examples of the invention will be described in con- 
junction with the drawings, in which: 

Figure 1 is a block diagram of a client computer sys- 
tem incorporating the present invention. 

Figure 2 is a functional block diagram of the opera- 
tion of the client computer system. 

Figure 3 is a flow chart of the compression method 
of the client computer system. 

Figure 4 is a flow chart of the decompression meth- 
od of the client computer system. 

Figure 5 shows an alternative embodiment of the 
client computer system. 

Figure 6 shows a functional block diagram of the 
operation of the alternative embodiment of the client 
computer system. 

DETAILED DESCRIPTION OF THE INVENTION 

Referring to Figure 1 , there is shown a computer 
network 1 00 in accordance with the present invention. 
It includes one or more client computer systems 102, 
one or more server computer systems 104, and a net- 
work communications connection 106. 

The client computer systems 102 are connected to 
the server computer systems 104 via the network com- 
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muntcations connection 106. The network communica- 
tions connection may be a local or wide area network, 
the Internet, or some other type of network communica- 
tions connection. 

Each server computer system 104 includes a cen- 
tral processing unit (CPU) 110, a user interface 112, a 
network communications interface 116, and a memory 
118. The network communications interface enables 
each server computer system to communicate with the 
client computer systems 102 via the network communi- 
cations connection 106. 

The memory 118 of each server computer system 
1 04 stores an operating system 1 20, a network commu- 
nications manager (or server) 122, and programs 145. 
The operating system and communications manager 
are all run on the CPU 120. The operating system con- 
trols and coordinates running of the network communi- 
cations manager in response to commands issued by a 
user with the user interface 112 or received by the net- 
work communications interface 116 via the network 
communications connection 106 from users of the client 
computer systems 102. 

The programs 145 comprise methods 147 and/or 
148. For purposes of this document, any discrete frag- 
ment or portion of a program that is invoked and not in- 
voked at various times during the execution of the pro- 
gram is considered a method. 

The methods 147 of each server computer system 
104 contain architecture neutral (AN) code that is inde- 
pendent of the specific architecture (i.e., platform) of the 
client computer systems 102. These programs are com- 
piled from a specific programming language into the AN 
code. In the preferred embodiment, these programs are 
written in the Java programming language and compiled 
into Java bytecode. Moreover, these programs are in- 
cluded in object classes with methods that form software 
programs which are programmed in an object-oriented 
manner. 

On the other hand, the methods 148 of each server 
computer system contain architecture specific (AS) 
code that is compiled lor the specific architecture of the 
client computer systems 102. As alludedto earlier, these 
kinds of methods are desirable in that they run faster 
than the same methods in AN code. As will be explained 
in greater detail later, it is preferred that the network 100 
be a closed and trusted network in which these pro- 
grams may be securely shipped to the client computers 
102 with a high degree of confidence or that these pro- 
grams have embedded digital signatures which can be 
verified. 

As will also be explained in more detail later, the 
methods 147 and/or 148 are transmitted upon user re- 
quest to the client computer systems 102 using the net- 
work communications manager 122. Thus, the code of 
these methods is considered network mobile code. 

Each client computer system 102 may be a video 
game, a personal digital assistant (PDA), a cellular 
phone, desktop computer, or other computer system or 
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computer operated device which requires a small 
amount of run-time memory. Furthermore, each client 
computer system includes a central processing unit 
(CPU) 126, a user interlace 128, a network communi- 
5 cations interface 132. a read only memory (ROM) 134, 
and a run-time random access memory (RAM) 1 36. The 
network communications interface enables the client 
computer system to communicate with the server com- 
puter systems 1 04 via the network communications con- 

10 nection 106. 

The RAM 136 of each client computer system 102 
stores an operating system 1 38, a network communica- 
tions manager 140, a virtual machine module 142, and 
a code compressor 1 46 that have all been loaded from 

15 the ROM 134. The RAM also stores the programs 145 
with methods 147 containing AN code and/or methods 
1 48 containing architecture specific (AS) code that have 
been downloaded from the server computer systems 
104. The operating system, network communications 

20 manager, virtual machine module, compiler, compres- 
sor, and programs are all executed on the CPU 126. The 
operating system controls and coordinates execution of 
the network communications manager, virtual machine 
module, code compiler, code compressor, and pro- 

25 grams in response to commands issued by a user with 
the user interface 128. 

As alluded to earlier, the methods 147 and/or 148 
are received from the server computer systems 104 up- 
on user request. These methods are obtained using the 

30 network communications manager 122 which is, in the 
preferred embodiment, a HotJava network communica- 
tions manager. The network communications manager 
then loads these methods in the RAM 136. 

The code verifier 1 51 of the virtual machine module 

35 1 42 verifies that the AN code of the loaded methods 1 47 
meets predefined integrity criteria. As mentioned earlier, 
this may include stack and data type usage restrictions 
to ensure that loaded methods cannot overflow or un- 
derflow the virtual machine module's stack and that all 

40 instructions utilize only data whose data type matches 
the data type restrictions for those instructions. In the 
preferred embodiment, the virtual machine module is a 
Java virtual machine module. 

However, in the case of the received methods 148 

45 with AS code, the code verifier 151 cannot be used to 
directly verify their integrity. Thus, to verify their integrity 
indirectly, the network 100 may be a closed and trusted 
network in which these methods may be securely 
shipped to the client computers 102 with a high degree 

50 of confidence. Aftematively, if the network 100 is not se- 
cure, these programs may have embedded digital sig- 
natures which enable the network communications 
manager 140 to verify that they are from a trusted 
source. 

55 The execution controller 1 53 of the virtual machine 
module 142 controls execution of the programs 145. In 
particular, the execution controller interprets the AN 
code of the methods 147 for execution on the specific 
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architecture of the client computer system 102 and en- 
ables these methods to call the methods 1 48 containing 
AS code for execution on the specific architecture. The 
execution 149 data generated during the execution ot 
the programs is stored in the RAM 136. In addition, if s 
the network communications manager 140, code com- 
piler 144, and/or code compressor 146 are in AN code, 
then the execution controller controls execution of them 
as well. 

Furthermore, in order to keep the RAM space re- 
quirements of the client computer system 102 low, the 
code compressor 146 compresses and decompresses 
in the RAM 1 36 the code of the methods 1 47 and/or 1 48 
at various times. This is done for the methods that are 
compressible and decompressive because they re- 
spectively satisfy predefined compression and decom- 
pression criteria 1 52 and 1 54 that are stored in the RAM 
1 36 and inputted by the user with the user interface 1 28. 
The compression and decompression criteria are more 
fully described later and are, in some embodiments of 
the present invention, user selectable and/or tunable 
(using the user interface 128) from a set of predefined 
memory management strategies. 

The storage and invocation status of the methods 
1 47 and/or 1 48 is maintained with the method status da- 
ta structures 1 55 The method status data structures are 
updated by the network communications manager 140, 
the execution controller 153, and the code compressor 
146. 

Figure 2 shows a functional block diagram of the 
operation of each of the client computer systems 102 in 
compressing and decompressing in the RAM 136 the 
methods 147 and/or 148. In addition, Figures 3 and 4 
respectively show the preferred compression and de- 
compression methods 300 and 400. 

Referiing to Figures 1-3, when a user requests ex- 
ecution of one of the programs 145 of one of the server 
computer systems 104, the user's client computer sys- 
tem 102 obtains the requested program from the server 
computer system (stop 302 of Figure 3). This is done 
when the user issues a command with the user interface 
128 to download and execute the program from the 
server computer system. In response, the operating 
system 120 calls the network communications manager 
140 which generates a message indicating that such a 
request has been made. The network communications 
interface 132 then transmits the message to the server 
computer system. 

The network communications interface 116 of the 
server computer system 104 receives the transmitted 
message. In response, the network communications 
manager 1 22 ol the server computer system provides 
the methods 147 and/or 148 of the requested program 
145 to the network communications interface which then 
transmits the methods to the user's client computer sys- 
tem 102. 

The methods 147 and/or 148 that were transmitted 
are received by the network communications interface 



132 of the user's client computer system 102. In re- 
sponse, the network communications manager 140 
then determines if enough space in the RAM 136 is 
available for loading the received methods (decision 
step 304 of Figure 3). If there is, then the network com- 
munications manager loads the code of these methods 
uncompressed into the available space in the RAM (step 
306 of Figure 3). As a result, these methods are loaded 
into the RAM along with previously loaded programs 
methods 147 and/or 148 of other programs 145. In load- 
ing these methods, the network communications man- 
ager updates the method storage status table 200 of the 
method status data structures 155 to identify the meth- 
ods and the corresponding pointers to the memory 
spaces in the RAM 136 occupied by these methods. 
Furthermore, the network communications manager up- 
dates the program status table to indicate that the code 
of the methods is uncompressed (U). 

The network communications manager 1 40 than in- 
vokes the code verifier 151 of the virtual machine mod- 
ule 142. In response, the code verifier verifies that the 
AN code of any methods 147 that were just loaded 
meets the predefined integrity criteria discussed earlier 
(step 307 of Figure 3). 

The program 145 whose methods 147 and/or 148 
were just loaded is then executed under the control of 
the execution controller (step 31 4 of Figure 3) along with 
any previously loaded programs. As the programs are 
executed, their methods are invoked and not invoked at 
various times during their execution. As mentioned pre- 
viously, the execution controller interprets the AN code 
of the methods 147 for execution on the specific archi- 
tecture of the user's client computer system 1 02 and en- 
ables these methods to call the methods 1 48 containing 
AS code for execution on the specific architecture. 

Each of the loaded methods 147 and/or 148 may 
not be invoked at various times because it may have to 
wait for data, may have been put to sleep, etc... When 
the execution controller determines that this has oc- 
curred, it adds the method to the least recently invoked 
(LRI) list 202 of the program status data structures 155 
to indicate that it is currently not invoked. The methods 
in the LRI list are listed from most recently invoked to 
least recently invoked. 

As indicated earlier, in order to reduce the space 
requirements of the RAM 136, the code of each loaded 
method 147 and/or 148 for which the predefined com- 
pression criteria 152 is satisfied is compressed by the 
code compressor 1 46. In the preferred embodiment, the 
compression criteria specifies that the code of a com- 
pressible method 1 47 or 1 48 be compressed at the time 
when (1 ) space in the RAM 1 36 is needed but not avail- 
able, and (2) the method is the least recently invoked 
method in the LRI list 202 that has not yet had its code 
compressed. 

When the network communications manager 140 
determines that space in the RAM 1 36 is not available 
to load one or more of the methods 147 and/or 148 re- 
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ceived by the server computer systems 104 (decision 
step 304 of Figure 3), then it invokes the code compres- 
sor 146. In response, the code compressor compresses 
the code of the least recently invoked method(s) in the 
LRI list 202 whose code has not yet been compressed 5 
until enough space has been made available (step 316 
of Figure 3). The code compressor also updates the 
method storage status table 200 to identify the corre- 
sponding pointer(s) to the memory space(s) of the com- 
pressed code of the method(s) and to indicate that the io 
code of the method(s) has been compressed (C). The 
network communications manager then loads the meth- 
od(s) for which space has been made available into the 
available space, as described earlier (step 306 of Figure 
3). 75 

The code compressor 146 may use any fast data 
compression technique well known to those skilled in 
the art. Moreover, the code compressor may use sepa- 
rate compression techniques for optimal compression 
of the AN code of the methods 147 and the AS code of 20 
the methods 1 48. 

Furthermore, while the loaded methods 147 and/or 
1 48 are invoked, they generate execution data. For any 
of these methods which the execution controller 1 53 de- 
termines is invoked (decision step 320 of Figure 3) and 25 
for which space in the RAM 1 36 is available to store ex- 
ecution data (decision step 322), the execution control- 
ler stores the execution data in the RAM (step 324 of 
Figure 3). 

However, for each of the loaded methods 1 47 and/ 30 
or 148 which the execution controller 153 determines is 
invoked (decision step 320 of Figure 3) and for which 
space in the RAM is not available but needed to store 
execution data (decision step 322), the execution con- 
troller invokes the code compressor 146. As in the ear- 35 
lier situations where space in the RAM is needed, the 
code compressor compresses the code of the least re- 
cently invoked method(s) in the LRI list 202 whose code 
has not yet been compressed until enough space has 
been made available (step 326 of Figure 3). And, as de- 40 
scribed earlier, the code compressor updates the meth- 
od storage status table 200 to identify the corresponding 
pointer(s) to the memory space(s) of the compressed 
code of the method(s) and to indicate that the code of 
the method(s) has been compressed (C). The execution 45 
controller then stores the execution data in the space 
made available in the RAM (step 324 of Figure 3), as 
described earlier, and execution of the program with the 
method(s) whose execution data was stored continues 
(step 314 of Figure 3). so 

Moreover, referring to Figures 1 , 2, and 4, when 
space in the RAM 1 36 is available, each loaded method 
147 and/or 148 that is compressed and for which the 
predefined decompression criteria 1 54 is satisfied is de- 
compressed by the code compressor 146. In the pre- ss 
ferred embodiment, the predefined decompression cri- 
teria 1 54 for decompressing a decompressive method's 
code simply specifies that the code of the method is 



\ 

911 A2 10 

compressed and is to be decompressed at the time 
when the method is to be invoked again. 

Thus, whenever the execution controller 153 deter- 
mines that one of the loaded methods 147 and/or 148 
is to be invoked (decision step 402 of Figure 4), it deter- 
mines whether the code of this method is compressed 
(decision step 404 of Figure 4) This is determined from 
the method storage status table 200. If the method's 
code isn't compressed, then the method is invoked by 
the execution controller (step 406 of Figure 4). When it 
is no longer invoked, its code may be compressed by 
the code compressor 146 in the manner described ear- 
lier. 

However, if the code of the method 147 or 1 48 that 
is to be invoked is compressed, then the execution con- 
troller invokes the code compressor 1 46 to decompress 
the method's code. The code compressor determines if 
there is enough space available in the RAM 136 to de- 
compress the code (decision step 408 of Figure 4). If 
there is enough space available, the code compressor 
decompresses the code in the available space (step 41 0 
of Figure 4). In doing so, it updates the method storage 
status table 200 to identify the corresponding pointer(s) 
to the memory space(s) of the uncompressed code and 
to indicate that the method's code is now uncompressed 
(U). 

However, if there is not enough space available, 
then the code compressor 146 compresses the code of 
the least recently executed method(s) in the LR1 list 202 
whose code has not yet been compressed until space 
has been made available (step 412 of Figure 4). This is 
done in the manner described earlier. After the space 
has been made available, the code of the method 147 
or 1 48 that is to be decompressed is decompressed by 
the code compressor in the available space and then 
invoked by the execution controller 153 in the manner 
just described (steps 410 and 406 of Figure 4). 

In view of the foregoing, it is clear that the described 
embodiment provides a reduction in run-time memory 
space while saving execution speed. This is due to the 
fact that by compressing the loaded methods 147 and/ 
or 148, they do not need not be flushed from the RAM 
136 and re-downloaded from the server computer sys- 
tems 104 when space in the RAM is needed. However, 
as those skilled in the art will recognize, other alternative 
embodiments could be implemented to provide similar 
benefits. 

Specifically, the compression criteria 1 52 described 
earlier specified that the code of least recently executed 
methods 147 and/or 148 with uncompressed code 
would be compressed when space in the RAM 1 36 was 
needed but not available. However, the compression cri- 
teria may be selected by the user from a broad range of 
options and based on a number of conditions specific to 
the user's client computer system 1 02. For example, the 
compression criteria may simply specify that the code 
of each method is to be compressed as soon as the 
method is no longer invoked. Or, it may specify that the 
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cods of certain methods is to be compressed lazily 
whenever time is available for doing so. As an additional 
variation of any of the foregoing, the compression crite- 
ria may specify that only the code of methods of a spe- 
cific size or type is to be compressed. 

Moreover, as was stated earlier, the decompression 
criteria 154 specified that a method 147 or 148 whose 
code is compressed code would have its code decom- 
pressed as soon as the method was to be invoked. How- 
ever, the decompression criteria could specify that the 
compressed code be decompressed after a predeter- 
mined time interval has expired. In this case, the data 
compressor would include a timer to time the time inter- 
val. In one example, this technique could be used for a 
method that is being put to sleep for a known time inter- 
val so that the method will be compressed for this time 
interval and then decompressed just prior to when it is 
to be awakened. Or, in another example, the technique 
could be used for a method that is waiting for data where 
the time interval over which the method is compressed 
would be selected so as to predict when the data will 
become available for the method. 

In another embodiment, the compression criteria 
152 may also include flushing criteria specifying when 
the loaded methods 147 and/or 148 are to be flushed 
from the RAM 1 36. For example, the flushing criteria 
may indicate that if there are no more loaded methods 
in the RAM that are not invoked and uncompressed, 
then the least recently executed method(s) in the LRI 
list 202 with compressed code are flushable and are to 
be flushed from the RAM 136 until enough space is 
made available. As a result, when a method is flushed 
from the RAM and then is to be executed again : the net- 
work communications manager 140 must re-download 
the program from the server computer system 104 that 
supplied the program in the manner discussed earlier. 
The execution controller 153 updates the program stor- 
age status table 200 by removing reference to any 
flushed methods. 

Since flushing loaded methods 1 47 and/or 1 48 from 
the RAM 1 36 is costly in terms of execution speed, a 
secondary memory 500 cou Id be used to store the meth- 
ods that would otherwise be flushed, as shown in Fig- 
ures 5 and 6. In this case, the compression criteria 152 
discussed earlier would include secondary storage cri- 
teria that would be similar to the flushing criteria just dis- 
cussed and used to store methods that are storable be- 
cause they satisfy the secondary storage criteria. How- 
ever, in this case, the code compressor 146 would up- 
date the pointers in the program storage status table 200 
to point to these methods in the secondary memory. Fur- 
thermore, for the methods that are retrievable in that 
their code is compressed, stored in the secondary mem- 
ory, and is to be decompressed, the code of the methods 
would be retrieved from the secondary memory and 
then decompressed in the RAM 1 36 in the manner de- 
scribed earlier. 

Moreover, in an embodiment where the client com- 



puter system 102 includes a secondary memory 500 (e. 
g. a networked desktop computer), the methods 147 
and/or 148 could be downloaded from the server com- 
puter systems 104 to the secondary memory. Then, 

5 these methods could be loaded directly into the RAM 
136 from the secondary memory rather then from the 
server computer systems 104. Additionally, in such an 
embodiment, the operating system 138, the network 
communications manager 140, the virtual machine 

10 module 142, and the code compressor 146 could be 
stored in the secondary memory and loaded from there 
into the RAM. 

In still another embodiment, the operating system 
1 38, the network communications manager 1 40, the vir- 

15 tual machine module 1 42, and the code compressor 1 46 
could be downloaded from one of the server computer 
systems 104 into the RAM 136 of the dient computer 
system 102. This would be done in a similar manner as 
that described earlier for the methods 1 47 and/or 1 48 of 

20 a server computer system. 

In yet another embodiment, the virtual machine 
module 1 42 is actually implemented in a silicon chip and 
serves as the CPU 126 of the client computer system 
102. In this case, the methods 147 with AN code are not 

25 interpreted for a specific architecture and are instead 
executed directly. In this embodiment, methods 1 48 with 
AS code would not be utilized. 



3 computer network over which is provided pro- 
ms with methods, a client computer system for 
scuting the programs with reduced run-time 
mory space requirements, the client computer 
item comprising: 

an run-time memory; 

a network communications interface that re- 
ceives the methods; 

a network communications manager that loads 
the methods uncompressed into available 
space in the run-time memory when received; 
an execution controller that controls execution 
of the programs, whereby the methods are in- 
voked and not invoked at different times; 
a compressor that (A) compresses in the run- 
time memory compressible ones of the uncom- 
pressed methods that are not invoked, whereby 
space is made available in the run-time mem- 
ory, and (B) decompresses in available space 
in the run-time memory decompressible ones 
of the compressed methods so that the decom- 
pressible ones of the compressed methods 
may be invoked. 

2. The client computer system of daim 1 wherein the 
compressor decompresses the decompressible 
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ones of the compressed methods as soon as the 
decompressible ones o1 the compressed methods 
are to be invoked. 

3. The computer system of claim 1 wherein the com- 
pressor decompresses the decompressible ones of 
the compressed methods after a predetermined 
time interval. 

4. The client computer system of claim 1, 2 or 3, 
wherein the compressor compresses the com- 
pressible ones of the uncompressed methods as 
soon as the compressible ones of the uncom- 
pressed methods are no longer invoked. 

5. The client computer system of claim 1, 2 or 3, 
wherein the compressor compresses the com- 
pressible ones of the uncompressed methods when 
space in the run-time memory is needed but not 
available. 

6. The client computer system of any of claims 1 
through 5 further comprising: 

a least recently invoked list that lists those of 
the methods that are currently not invoked in 
order of least recently invoked method to most 
recently invoked method; 
the compressible ones of the uncompressed 
methods are the least recently executed meth- 
ods in the least recently executed list that are 
not compressed when space in the run-time 
memory is needed but not available. 

7. The client computer system of any of claims 1 
through 6, wherein: 

the methods include methods in architecture 
neutral code that is independent of the archi- 
tecture of the client computer system; and 
the client computer system further comprises a 
virtual machine module that includes the exe- 
cution controller and enables execution of the 
methods in the architecture neutral code. 

8. The client computer system of any of claims 1 
through 7. wherein the compressor flushes from the 
run-time memory fiushable ones of the compressed 
methods when space in the run-time memory is 
needed but not available. 

9. The client computer system of any of claims 1 
through 8 further comprising: 



14 

is needed but not available, and (B) retrieves 
from the secondary memory retrievable ones of 
the compressed methods that are to be decom- 
pressed. 

5 

10. In a computer network over which is provided pro- 
grams with methods, a method ol executing the pro- 
grams with reduced run-time memory space re- 
quirements, the method comprising the steps of: 

70 

providing an run-time memory; 
receiving the methods; 

loading uncompressed into available space in 
the run-time memory the methods when they 

is are received; 

executing the programs, whereby the methods 
are invoked and not invoked at different times; 
compressing in the memory compressible ones 
of the uncompressed methods that are not in- 

20 voked, whereby space is made available in the 

run-time memory; and 

decompressing into available space in the run- 
time memory decompressible ones of the com- 
pressed methods so that the decompressible 
25 ones of the compressed methods may be in- 

voked. 

11 . The method of claim 1 0 wherein the decompressing 
step includes decompressing the decompressible 

30 ones of the compressed methods as soon as the 
decompressible ones of the compressed methods 
are to be invoked. 

12. The method of claim 1 0 wherein the decompressing 
35 step includes decompressing the decompressible 

ones of the compressed methods after a predeter- 
mined time interval. 

1 3. The method of claim 19, 11 or 1 2, wherein the com- 
40 pressing step includes compressing the compress- 
ible ones of the uncompressed methods as soon as 
the compressible ones of the compressed methods 
are no longer invoked. 

45 14. The method of claim 10, 11 or 12, wherein the com- 
pressing step includes compressing the compress- 
ible ones of the uncompressed methods when 
space in the run-time memory is needed but not 
available. 

so 

15. The method of any of claims 10 through 14 lurther 
comprising the steps of: 

providing a least recently invoked list that lists 
those of the methods that are currently not in- 
voked in order of least recently invoked method 
to most recently invoked method; 
the compressible ones of the uncompressed 



a secondary memory; 55 
the compressor (A) stores in the secondary 
memory storable ones of the compressed 
methods when space in the run-time memory 
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methods are the least recently invoked meth- 
ods in the least recently invoked list that are not 
compressed when space in the run-time mem- 
ory is needed but not available. 

16. The method ot any of claims 10 through 15 further 
comprising the step ot flushing from the run-time 
memory Nushable ones of the compressed methods 
when space in the run-time memory is needed but 
not available. 

17. The method of any of claims 10 through 16 further 
comprising the steps of: 

providing a secondary memory; 
storing in the secondary memory storable ones 
of the compressed methods when space in the 
run-time memory is needed but not available; 
and 

retrieving from the secondary memory retriev- 20 
able ones of the compressed methods that are 
to be decompressed. 
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